There is no `publish.profile` property in the `.asf.yaml` schema.

Fixes #3598

The Javadoc site generation broke after upgrading to Maven Javadoc Plugin 3.10.0 due to a change in the output directory structure (see apache/maven-javadoc-plugin#1163).
This update adjusts our build script to look in the new output location, restoring proper Javadoc generation.

Closes #3753

> [!NOTE]
> This change has already been applied to `2.x-site-pro`

…g Java 8 (#3762)

…j-bom` to `log4j-parent` (#3763)

Bumps [org.apache.activemq:activemq-broker](https://github.com/apache/activemq) from 6.1.6 to 6.1.7.
- [Commits](apache/activemq@activemq-6.1.6...activemq-6.1.7)

---
updated-dependencies:
- dependency-name: org.apache.activemq:activemq-broker
  dependency-version: 6.1.7
  dependency-type: direct:production
  update-type: version-update:semver-patch
...

Signed-off-by: dependabot[bot] <[email protected]>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>

…on `2.7.16` (#3769)

Co-authored-by: ASF Logging Services RM <[email protected]>

Co-authored-by: ASF Logging Services RM <[email protected]>

This change explicitly defines the version of the `error_prone_annotations` dependency in the `log4j` parent POM.

Previously, the version was inherited via the `error-prone.version` property from `logging-parent`. However, because the `log4j-bom` POM is flattened during publication, this property no longer resolves in consumer projects.

Fixes #3779

### fix(test): fail `DisruptorTest` on async thread exceptions

Ensure that DisruptorTest explicitly fails when an exception occurs on an asynchronous thread. This improves error detection and prevents silent test passes in the presence of async failures.

### fix: correctly detect Disruptor major version

Ensure the Disruptor version is detected using the classloader that loaded `DisruptorUtil`, rather than the thread-context classloader. The previous implementation relied on `LoaderUtil.isClassAvailable`, which may fail in environments where the Disruptor classes aren't visible to the thread-context classloader.

Fixes #3771

This PR makes the `-Alog4j.graalvm.groupId` and `-Alog4j.graalvm.artifactId` arguments optional.

* If **no arguments** are provided, metadata is stored in:

  ```
  META-INF/native-image/log4j-generated/<content-derived-value>
  ```
  Previously an error was thrown.

* If **arguments are provided**, files go to:

  ```
  META-INF/native-image/log4j-generated/<groupId>/<artifactId>
  ```
  Previously `META-INF/native-image/<groupId>/<artifactId>` was used. The new path prevents collisions with user-provided metadata.

Co-authored-by: Copilot <[email protected]>

…3773)

### feat: add tests for `LoggerContext.start` behavior

Add test verifying expected behavior of `LoggerContext.start(Configuration)` to ensure backward compatibility:

- The configuration must always be replaced, even if the context has already started.
- Only the first configuration should register the shutdown hook.

### fix: Restore Backward Compatibility with Spring Boot Reconfiguration

Although Spring Boot never directly starts a `LoggerContext`, its logging system — including our `Log4j2SpringBootLoggingSystem` and equivalents in Spring Boot 2.x and 3.x — has consistently used `LoggerContext.start(Configuration)` for reconfiguration.

This use case was not taken into consideration in #2614, causing a regression for Spring Boot users.

To maintain backward compatibility with these usages, `start(Configuration)` now falls back to `reconfigure(Configuration)` if the context is already started.

Closes #3770

Fixes #3787

)

This update refines the `GraalVmProcessor` configuration example in response to feedback from #3755. The goal is to make the example more reliable and aligned with common Maven project setups. Key improvements include:

* **Ensuring consistent parameter usage:**
  The example now adds `-Alog4j.graalvm.groupId` and `-Alog4j.graalvm.artifactId` to **all executions** of the Maven Compiler Plugin. This guarantees correct behavior regardless of the execution ID used in user projects.

* **Simplifying plugin execution setup:**
  Instead of introducing a dedicated `generate-log4j-plugin-descriptor` execution, the example now modifies the existing `default-compile` execution. This reflects the most typical use case, where annotation processing and compilation occur together.

These changes aim to make the setup easier to adopt while reducing configuration errors.

This update fixes the GraalVM reachability metadata generation for methods with annotated array parameters, such as `@Nullable String[]`.

Previously, the code computed the fully qualified class name for the parameter using the **raw** type, which retained the annotations (e.g., `@org.jspecify.annotations.Nullable java.lang.String`). This resulted in incorrect metadata that was ignored by GraalVM.

The issue is resolved by transforming the `DeclaredType` into a `TypeElement`, effectively removing any annotations, and then calling `getQualifiedName()` to correctly generate the fully qualified class name without annotations.

…j-parent (#3745)

* Update `com.fasterxml.jackson:jackson-bom` to version `2.19.1` (#3745)

* Empty commit to trigger required checks

---------

Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Co-authored-by: Piotr P. Karwasz <[email protected]>

Co-authored-by: ASF Logging Services RM <[email protected]>

Co-authored-by: ASF Logging Services RM <[email protected]>

This change disables the sharing of formatted timestamps between threads in `InstantPatternThreadLocalCachedFormatter`.

Previously, a mutable `StringBuilder` was shared across threads via a cached object. This could lead to situations where one thread ("owner") was modifying the builder while another thread was reading from it, resulting in inaccurate or truncated timestamps.

This fix ensures that only thread-local instances are used, preventing concurrency issues and improving timestamp correctness under load.

This change is similar in nature to #1485 and fixes #3792.

…tions (#3800)

The `GraalVmProcessor` currently only generates metadata for Log4j plugins, overlooking other reflection usages in Log4j Core. This change adds reachability metadata for additional reflection cases to improve compatibility with GraalVM native images.

### Fixed Cases

This PR addresses the following reflective instantiations:

* **Context selectors and reliability strategies:** Ensures proper instantiation under GraalVM.
* **`Configuration` instantiation in `DefaultConfigurationBuilder`:** Fixes support for the `log4j2.properties` configuration format when running on GraalVM.
* **`BlockingQueue` instantiation in JSON Template Layout:** Enables GraalVM compatibility. Note: `MpmcArrayQueue` is not supported on GraalVM and must be fixed in the JCTools project.

### Known Limitations (Explicitly Ignored)

The following cases are *not* addressed in this PR:

* **JMX classes in `log4j-1.2-api`:** While GraalVM supports JMX, usage of Log4j 1.x’s JMX interface is likely minimal.
* **`MulticastDnsAdvertiser`:** This feature is probably unused and could pose a security risk by advertising log file locations via mDNS.

* fix: Add `resource:` protocol to allowed URL schemes by default

This update includes `resource:` in the list of allowed URL schemes for retrieving configuration files.
See [`log4j2.configurationAllowedProtocols`](https://logging.apache.org/log4j/2.x/manual/systemproperties.html#log4j2.configurationAllowedProtocols)

Currently, the `resource:` protocol is used exclusively by a `URLStreamHandler` that retrieves files from the embedded resources in a GraalVM native image. This makes it a secure and appropriate source for trusted configuration files.

This change cannot be easily and reliably tested through a unit test. An integration test will be provided in apache/logging-log4j-samples#345

Closes #3790

* fix: Add `resource` protocol only in native images

This change introduces an internal `SystemUtils.isGraalVm()` method to detect the presence of GraalVM and enable the `resource` protocol.

* Reword changelog entry

---------

Co-authored-by: Volkan Yazıcı <[email protected]>

This change merges the changes of the `release/2.25.1` branch back into
the development branch.